Poster: User Request as a means to Automate Authorization Hook Placement

We consider the problem of retrofitting legacy software with mechanisms for authorization policy enforcement. This is an important problem for operating systems, middleware and server applications (jointly, servers), which manage resources for and provide services to multiple, mutually-distrusting clients. Such servers must ensure that when a subject requests to perform a security-sensitive operation on an object, the operation is properly authorized. This goal is typically achieved by placing calls (termed authorization hooks) to a reference monitor [1] at suitable locations in the code of the server. At runtime, the invocation of a hook results in an authorization query that specifies the subject, object, and operation. The placement of authorization hooks must provide complete mediation of security-sensitive operations performed by the server. If this property is violated, subjects may be able to access objects even if they are not authorized to do so. In the past decade, several efforts have attempted to place authorization hooks in a variety of servers. For example, discretionary access control mechanisms deployed in the Linux kernel were found to be insufficient to protect the security of hosts in a networked world. The Linux Security Modules (LSM) framework remedies this shortcoming by placing authorization hooks to enforce more powerful security policies. Even user-space servers can benefit from similar protection. For example, the X server manages windows and other objects for multiple clients. Accesses to such objects must be mediated, void of which several attacks are possible. The X server has also therefore been retrofitted with LSM-style authorization hooks [4]. Similar efforts now abound for other server applications (e. Unfortunately, these efforts have been beset with problems. This is because the identification of security-sensitive operations and the placement of hooks is a manual procedure, largely driven by informal discussions on mailing lists in the developer community. There is no consensus on a formal definition of what constitutes a security-sensitive operation, and no tool support to identify their occurence in large code-bases. Not surprisingly, this ad hoc process has resulted in security holes, in some cases many years after hooks were deployed [8]. The discussion of which hooks to deploy can often last years, e.g., the original hook placement for the X server was proposed in 2003 [4], deployed in 2007 [9], and subsequent revisions have added additional hooks. What we therefore need is a principled way to identify security-sensitive operations and their occurrence in code, so that legacy …